home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group99a.txt / 000108_icon-group-sender _Wed Apr 28 12:33:24 1999.msg < prev    next >
Internet Message Format  |  2000-09-20  |  4KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA28778
  4.     for icon-group-addresses; Wed, 28 Apr 1999 12:32:08 -0700 (MST)
  5. Message-Id: <199904281932.MAA28778@baskerville.CS.Arizona.EDU>
  6. Delivered-To: icon-group@cs.arizona.edu
  7. From: "Mark Evans" <evans@gte.net>
  8. To: <icon-group@optima.CS.Arizona.EDU>
  9. Subject: RE: Modula 3
  10. Date: Wed, 28 Apr 1999 10:34:18 -0500
  11. X-Priority: 3 (Normal)
  12. X-MSMail-Priority: Normal
  13. X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
  14. Importance: Normal
  15. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  16. Status: RO
  17.  
  18. To reiterate, I asked for a utility comparison of Modula-3 with Icon, not with
  19. all the other languages in the world:
  20.  
  21. "My question was about practical field experience from people who have used both
  22. Icon and Modula-3 in the field, for real projects."
  23.  
  24. You say "pretty good performance" but your comments are relative to languages
  25. other than Icon.  What is the performance relative to Icon?  How does the GUI
  26. Kit for Modula 3 compare to the GUI Kit for Icon?  How easy is it to code Modula
  27. 3 vs. Icon?  Etc.
  28.  
  29. As far as the evolution of Icon -- Icon is by its own admission a small
  30. language, and I daresay that its main features (string parsing, goal-direction)
  31. could be incorporated into other languages wholesale.  The impetus for this line
  32. of questioning is the notion that Icon is not good for large-scale projects,
  33. whereas Modula-3 claims that's what it was made for.
  34.  
  35. Mark
  36.  
  37.  
  38.  
  39. -----Original Message-----
  40. From: icon-group-sender@CS.Arizona.EDU
  41. [mailto:icon-group-sender@CS.Arizona.EDU]On Behalf Of Richard A. O'Keefe
  42. Sent: Tuesday, April 27, 1999 6:41 PM
  43. To: evans@gte.net; icon-group@CS.Arizona.EDU
  44. Subject: RE: Modula 3
  45.  
  46.  
  47.     Modula 3 is supposed to be capable of handling vast software systems without
  48. all
  49.     the header file nightmares of C++.  It is supposed to capture essentially all
  50.     the good and "proven" features of modern software compiler design practice,
  51.     without all the bad stuff (but still allowing for low-level machine access as
  52.     required, in controlled interfaces).  Whether it was based on Pascal or BASIC
  53. or
  54.     FORTRAN or C or Ada does not answer the question of the Modula-3 language's
  55.     practical utility as it exists today, in comparison to Icon.  The blurbs for
  56.     Icon make a lot of similar claims.
  57.  
  58. You can think of Modula 3 as a poor man's Ada 95
  59.     PLUS required garbage collection
  60.     PLUS a GUI kit of its own instead of Ada's X and Windows bindings.
  61. Modula-3 should give you pretty good performance, but probably won't
  62. match Ada or SmallEiffel.  If only Ada 95 systems all had garbage
  63. collection (instead of only some of them) I don't know why anyone
  64. would use Modula-3.
  65.  
  66.     The blurbs I have read from the Modula-3 home page indicate that
  67.     some groups of experienced C++ programmers never looked back
  68.     after using Modula-3.
  69.  
  70. That's largely because C++ is uniquely horrible.  "Header file nightmares"
  71. are confined to C-like languages; Simula 67 had full typesafe separate
  72. compilation without any of that nonsense back in the late 60s.  If you want
  73. a decent OO language with generics, Eiffel and Sather deserve as much
  74. consideration as Modula-3, and Eiffel has multiple implementations.
  75.  
  76.     Maybe another way to ask my question is this:  if Icon evolves,
  77.     should it evolve in the direction of Modula-3?  Even partly?
  78.  
  79. It couldn't, not without changing its character so much as to be
  80. unrecognisable.  Icon *could* evolve in the direction of ISETL, Pop-11,
  81. or Lisp without losing too much; indeed, if you get Jeff Siskind's
  82. SCREAMER package for Lisp, you end up with a rather more powerful
  83. language than Icon but in much the same spirit.  (To start with, the
  84. Common Lisp Object System is the most powerful in existence, far beyond
  85. anything Modula-3 can muster.)
  86.  
  87.   You could *possibly* bolt some kind of Haskell-like type system on top
  88. of Icon and still salvage much of the language (there's an interesting
  89. M.Sc.  topic), but not a Modula-3-like type system, and it's only a
  90. little exaggeration to say that the type system _is_ Modula-3.
  91.  
  92.  
  93.  
  94.